Re: [mpls] LDP IPv6

Vishwas Manral <vishwas.ietf@gmail.com> Fri, 13 August 2010 17:16 UTC

Return-Path: <vishwas.ietf@gmail.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DCC93A6864 for <mpls@core3.amsl.com>; Fri, 13 Aug 2010 10:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H68gDjm02Io8 for <mpls@core3.amsl.com>; Fri, 13 Aug 2010 10:16:33 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 877EC3A67EE for <mpls@ietf.org>; Fri, 13 Aug 2010 10:16:33 -0700 (PDT)
Received: by qyk1 with SMTP id 1so103675qyk.10 for <mpls@ietf.org>; Fri, 13 Aug 2010 10:17:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=uLwpSQuuRxEZNhbHRAPeer7uoxFOLzhsdZpcQScOSN8=; b=uPANpd/mhNTjJxf+3/qKlWE0+OeJdHOiZbgOiZFc4+nvJtMBdnMdXPz0T29D3I9XsX PAHmPmKHPlx3+1DvoJ6wO7GkhcLkrG3LuahUz5+flQlnIOJ7irVcS6j5Yb0LwtChmW/+ 5hd6PxotFIuYJXq5ZUN9qTQZSpNb5cFPaV3M8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UVsQGw1DSyHOWD/l5m6egOZG6L0EWI2TmZJNQe7kYXJYYBobL3iAW5bXDvlYMjlOkM WBiygjjuY0vBau2Dqg4V+l/9sP9dpCmWmyuoBV0clihg9nn/C9aQFDuSiyL+V3n6HMyT YQPB0esXR2/S5GNDQ1NbL5s/OCpZ8kbOkxPgU=
MIME-Version: 1.0
Received: by 10.224.53.35 with SMTP id k35mr1199849qag.250.1281719830246; Fri, 13 Aug 2010 10:17:10 -0700 (PDT)
Received: by 10.229.109.207 with HTTP; Fri, 13 Aug 2010 10:17:09 -0700 (PDT)
In-Reply-To: <1ED479097DCF154A89226065E522D5A80273C7C8@XMB-RCD-102.cisco.com>
References: <h2g77ead0ec1004061223k7cc69585ncf8761efb0df2d33@mail.gmail.com> <4395962A7C18D84191B205AD7089698305CA00CA@S4DE9JSAAIB.ost.t-com.de> <r2h77ead0ec1004120755za2c9aadcw9184a1d56cd10c5b@mail.gmail.com> <q2s77ead0ec1004120940r875bc282y7edd293bd846c57@mail.gmail.com> <1E2FA684-E5E0-45FA-9885-0BA7C288AC08@eng.gxn.net> <alpine.DEB.1.10.1004150758320.6768@uplift.swm.pp.se> <x2k77ead0ec1004150817v5f2da373lce60f3827a5e00d7@mail.gmail.com> <o2r3c502ff41004160103qf32c87dbn9c9cfd67f057631a@mail.gmail.com> <v2s77ead0ec1004160659r93f30297k8e6f262bf9465a13@mail.gmail.com> <AANLkTinAGcPj2DUH8iUs0QxZTxoU9ikPdbwRq_Z1Pz7x@mail.gmail.com> <1ED479097DCF154A89226065E522D5A8026763B9@XMB-RCD-102.cisco.com> <AANLkTinBt0U_oK4xSUMFcDG_xbMYS4JjC17jEquzuRWK@mail.gmail.com> <1ED479097DCF154A89226065E522D5A80273C4A3@XMB-RCD-102.cisco.com> <5F6B9BB538604CFBAAD4395FAA70EE1C@m55527c> <1ED479097DCF154A89226065E522D5A80273C7C8@XMB-RCD-102.cisco.com>
Date: Fri, 13 Aug 2010 10:17:09 -0700
Message-ID: <AANLkTi=fy=OfwcZ10w7MRr9nOMvgM379dhnJYFp59kt7@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: "Bin Mo (bmo)" <bmo@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: mpls@ietf.org
Subject: Re: [mpls] LDP IPv6
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Aug 2010 17:16:34 -0000

Hi Bin,

I agree. There are two sides to the coin.

1. Have a definitive way of doing things. However what this means is
this can cause disruption. So if the IPv6 session comes up first it is
disrupted when the IPv4 session comes up later.
2. Not allowing disruption causes indefinitness.

We can take a call the other way too if the WG so decides.

Thanks,
Vishwas

On Fri, Aug 13, 2010 at 7:50 AM, Bin Mo (bmo) <bmo@cisco.com> wrote:
> Hi Mach,
>
> One problem of using LDP identifier to determine the active/passive role
> is backward compatibility, i.e. when you inter-op with old box, they
> will make decision based on different thing.
>
> It might be ok to use the IPv4 transport address to determine who plays
> active/passive role in setup IPv4 TCP, and similarly in setup IPv6 TCP.
>
> My problem is there isn't a determinative way for both sides to abandon
> the same connection. The proposed mechanism of abandon the later
> connection may means different connection on each side.
>
> Thanks
>
> /Bin
>
>> -----Original Message-----
>> From: Mach Chen [mailto:mach@huawei.com]
>> Sent: Friday, August 13, 2010 3:54 AM
>> To: Bin Mo (bmo); Vishwas Manral
>> Subject: Re: [mpls] LDP IPv6
>>
>> Hi Bin and Vishwas,
>>
>> --------------------------------------------------
>> From: "Bin Mo (bmo)" <bmo@cisco.com>
>> Sent: Thursday, August 12, 2010 11:43 PM
>> To: "Vishwas Manral" <vishwas.ietf@gmail.com>
>> Cc: <mpls@ietf.org>
>> Subject: Re: [mpls] LDP IPv6
>>
>> > RFC5036 says in session setup, one LSR plays passive role and the
>> other
>> > plays
>> > active role. For example, If based on the address, one LSR should
>> play
>> > passive
>> > role in IPv4 TCP connection and it aborts IPv6 TCP connection setup,
>> the
>> > other
>> > LSR should play passive role in IPv6 TCP connection and it aborts
>> IPv4 TCP
>> > connection setup, then they will have to re-try. Timing involves in
>> such
>> > situation
>> > but could happen.
>>
>> When implement this IPv4 and IPv6 mixed function, we found the same
>> issue.
>> So, if based on the LDP identifier to detemine the active/passive
> role,
>> there will not be such a problem. How do you think?
>>
>> Best regards,
>> Mach
>
>